MemSystem ist ein Speicherverwaltungsmodul, das gegenüber dem Standardmodul "Heap" folgende Vorteile aufweist:
* es ist voll Multitaskingfähig, d.h. es kann vom Hauptmodul importiert und von mehreren Tasks aus parallel benutzt werden. Dabei wird allozierter Speicher immer in der MemList des aufrufenden Tasks eingetragen. Bei Beendigung des Tasks (mit RemTask oder bei Process-Termination) wird der gesammte mit MemSystem verwaltete Speicher freigegeben.
* Wird mehr Speicher angefordert als frei ist, wird dies nicht sofort mit NIL beantwortet, sondern ein Requester (Retry/Cancel) erzeugt. Der Benutzer hat somit die Möglichkeit, z.B. einige Workbench-Windows zu schlieÃen, um es dann noch einmal zu probieren. Der Programmieraufwand ist praktisch null, entgegen der sonst üblichen Methode, dach jedem AllocMem() auf NIL zu testen, den Requester anzuzeigen ...
* System-Deadlocks, die durch extremen Speichermangel hervorgerufen werden können, werden verhindert. Viele Programme erzeugen bei Speichermangel eine Meldung mit AutoRequest() (zB. auch der Modula-Compiler). Es wird aber oft vergessen, daà der Requester selbst auch Speicher benötigt. MemSystem berücksichtigt dies.
AuÃerdem wurden noch einige nützliche Prozeduren implementiert:
* Eine vereinfachte AutoRequest()-Prozedur
* Prozeduren zum Abbruch des Programms entweder über Retry-Cancel- Requester oder ähnlich der Arts.Error-Prozedur oder ohne irgendeine Meldung
Allocate, AllocMem, Deallocate
Diese Prozeduren entsprechen in der Schnittstelle sowie in der Handhabung genau den gleichnamigen Prozeduren von Heap. Allerdings läuft beim allozieren von Speicher für das aufrufende Programm unsichtbar noch folgendes ab:
* Es wird getestet, ob Size+MinMemory Speicher frei ist.
* falls nicht wird ein Requester (Low Memory Warning Retry/Cancel) erzeugt. Bei "Retry" wird noch einmal versucht, die angeforderte Speichermenge zur verfügung zu stellen. Bei "Cancel" wird NIL zurückgegeben, wie man es von Heap bei Speichermangel kennt.
* falls doch wird der Speicher wie gewohnt alloziert. Der Speicherbereich wird in der MemList des aufrufenden Tasks oder Prozesses registriert. Einwandfreie Funktion ist auch bei mehreren parallellaufenden Tasks, die auch unabhängig voneinander erzeugt und terminiert werden können, gewährleistet. Die Prozeduren sind reentrant.
Ein Deallozieren von Speicher, den man gar nicht alloziert hat führt nicht zum Guru, sondern wird abgefangen.
YesNoRequest
Dies ist eine Vereinfachung von AutoRequest(). Sie wird intern von Allocate, AllocMem (bei Speichermangel) und von RecoverableExit verwendet. Als "Zugabe" wurde die Prozedur auch im Definition-Module aufgeführt und somit für jedermann zugänglich gemacht. Die Parameter dürften selbsterklärend sein (siehe auch Intuition.AutoRequest).
RecoverableExit
Dies ist gewissermaÃen die Kombination aus Arts.BreakPoint und Arts.Error. Während BreakPoint nach beantworten des Requesters immer weitermacht, und Error immer abbricht, kann der Benutzer bei RecoverableExit selbst entscheiden.
Die Prozedur verwndet die Variablen Window und ErrHeader (siehe dort).
ReqBody: Zeiger auf den String der "Requester-Ãberschrift"
PosText: Zeiger auf den Text im linken Gadget (Programm fortsetzen)
NegText: Zeiger auf den Text des rechten Gadget (abbrechen)
DeadEndExit
Entspricht Arts.Error, mit dem Unterschied, daà nicht die häÃliche Meldung "Modula-2 Programmunterbruch" erscheint. Stattdessen wird ErrHeader (siehe unten) und darunter ReqBody angezeigt.
ExitQuiet
ermöglicht das korrekte beenden des Programms von jeder beliebigen Stelle aus (auch vom 671sten rekursiven Funktionsaufruf...). Ebenso wie auch bei DeadEndExit und RecoverableExit funktioniert hierbei der TermProcedure-Mechanismus ordnungsgemäÃ.
Window
Diese Variable wird beim Aufruf von AutoRequest() durch MemSystem verwendet und sollte vor Verwendung von Prozeduren dieses Moduls initialisiert werden. Zwar funktioniert meines Wissens nach auch alles einwandfrei, wenn "Window" nicht initialisiert ist bzw. auf NIL steht, aber mit rücksicht auf die Aufwärtskompatiblität sollte man sich trotzdem an die Konventionen halten.
ErrHeader
Ist die Ãberschrift jedes Requesters, der von MemSystem erzeugt wird.
minMemory
gibt die gröÃe des Speichers an, der minimal noch freibleiben muÃ, damit die korrekte Funktion des Systems gewährleistet ist. Default ist 20kB, was für einige Notfall-Requester oder Alerts ausreicht.
Hysteresis
Damit nach einem Speichermangel wieder Speicher alloziert werden kann, muà mindestens minMemory+Hysteresis Speicher frei sein. Die Hysterese wurde eingeführt, damit bei einem Arbeiten an der minMemory-Grenze nicht all paar Sekunden ein Requester erscheint, sondern der Speicher nach einem erfolgreichen "Retry" wieder für eine Weile reicht. Default ist 30kB.
Konstanten
Für die Prozeduren YesNoRequest und RecoverableExit werden einige vordefinierte Texte wie z.B. "Retry", "Cancel" usw. bereitgestellt, um den Aufwand des Arbeitens mit MemSystem möglichst gering zu halten.
Multitasking
Die Multitaskingfähigkeit von MemSystem hat natürlich nur einen Sinn, wenn auch in Modula Multitasking programmiert werden kann. Zur Zeit arbeite ich gerade an einem Modul, das diese Fähigkeiten in Modula unterstützt. "TaskSupport" wird wahrscheinlich auf einer der nächsten Amok-Disketten erscheinen. Als Warnung sei gesagt, daà die Prozedur ExecSupport.CreateTask zumindest bis zur Compilerversion 3.11d nicht einwandfrei funktioniert (stürzt manchmal und nicht reproduzierbar ab). Falls jemand schon Erfahrungen mit Multitasking in Modula gemacht hat, würde es mich freuen, wenn er sich mit mir in Verbindung setzen würde.
___________________________
Viel Spaà mit MemSystem!
BeneDokumentation zu "MemSystem" Version 1.1Seite
Autor: Nicolas Benezan, Postwiesenstr.2, 7000 Stuttgart 60
(.txt)